In recent years, a trend is visible that people are putting more than one OSes on the same computer. In enterprise server arena, such a feature would allow IT departments to put one server into one VM and lead to much better manageability. In software development, it enables developers to quickly test out software portability on various OSes and various versions of the same OS. Even in personal computing, people start to use multiple OSes for supporting different applications and for testing out new OS versions, or just for testing out downloaded software. On embedded devices such as smartphones, people can have two OSes for different purpose: one for private usage and one for business usage.
The predominant technique for multi-OS is virtual machine (VM) technology, which was originally developed by IBM for mainframe computers. Virtualization technology typically uses a layer of software, often called VMM (virtual machine monitor), that sits between OSes and hardware. VMM manages the real hardware and provides abstract or virtualized hardware view to OSes running on top. Implementation and porting of VM technology are complex tasks. For example, in order to support guest OSes well, any underlying device needs to be virtualized one way or the other in order for the guest OS to access the device. With a growing list of new hardware coming out everyday, this restriction may limit the applicability of VM-based approaches. The VM approach offers very high switching speed. But compared with other approaches, they incur significant development costs, and they have lower runtime efficiency especially for I/O intensive applications.
Simple solutions exist to overcome these problems when the application does not require multiple OSes running concurrently. There are multi-boot solutions. A multi-boot approach essentially time-multiplexes all the hardware resources except for hard disks which are partitioned. Switching is done through rebooting. BootMagic from PowerQuest is an example of such approach. It allows a user to install multiple OSes on the same computer but on different hard disk partitions or on different hard drives. When computer boots up, user is prompted with a list of OS choices. User will select one and computer will runs the OS of the choice. If user ever wants to run another OS, he/she will need to reboot the computer and make a different selection during the start-up. Some OSes such as Windows don't like the presence of other OS instances and may insist to reside on the first partition of the first hard drive. Boot magic will have to modify hard driver petition table and even modify BIOS temporarily to provide that illusion to such OSes. All rebooting based approaches are essentially similar to this. For example, some computer allows one to select boot device, through which multiple OSes can be supported. The only difference is that the underlying implementation is hardware based or BIOS based.
The multi-boot approach almost incurs no development cost, and its runtime efficiency is as high as that of a single OS solution. The multi-boot approach, however, has a serious drawback in extremely slow switching speed and cumbersome switching overhead. It's not atypical to find that it takes 10 s of seconds to switch from one OS to another in a multi-boot solution. Therefore, it is not suitable for applications where one needs relatively fast and convenient switching between different OSes.
An example of OS switching is described in U.S. Patent Application no. US20010018717A1, entitled, “Computer system, operating system switching system, operating system mounting method, operating system switching method, storage medium, and program transmission apparatus”. The OS switching approach described therein does not attempt to virtualize any hardware components for supporting multiple OSes. In OS switching, all OS images are resident in partitioned system memory. A small OS switcher enables switching from one OS to another. Instead of virtualizing hardware components, when an OS runs, it sees and owns all the hardware of system (except that it only manages portions of system memory and storage). Switching under this arrangement is much faster than under multi-boot arrangements. Switching from OS1 to OS2 is achieved by first suspending OS1, and then resuming OS2. Implementations of OS switching use suspend/resume power management functions that already exist in OSes. The suspend process saves device states and powers off the devices, and the resume process powers on devices and restores device states.
Meanwhile, the implementation of OS switching is much simpler than VM-based technology, as there is no virtualization or abstraction layer between OSes and hardware. All the OSes run efficiently at native speed, and the new hardware support issue is delegated to each individual OS itself and is not a part of OS switcher.
However the switching time in current OS switching implementations is still much longer than those in VM systems. This long switching time makes impractical to use OS switching in certain application scenarios. For example, when OS #1 relies on OS #2 to decipher encrypted data, and when such decryption requests arise relatively frequently, it is impossible to use an OS switching based implementation because of the long switching latency.